Designing user interfaces (UIs) for clinicians is an especially difficult task because many clinicians may not have the time or patience to sit through comprehensive in-service sessions. One viewpoint of some clinicians is that if they have to read a manual to operate a medical device, then the designer of that device has failed, because in some urgent circumstances, they may be required to operate devices for which no manual is readily available, on which they have not been fully trained, or when they have not recently used the device to maintain proficiency. Many medical devices fail this pragmatic, real-world definition of intuitiveness and usability. Given that poor usability can affect the eventual outcome of a clinical procedure, a well-designed user-interface that anticipates the needs of clinicians is essential.
With the advent of inexpensive microprocessors, the flexibility and power of UIs programmed in software has opened the possibility of designing UIs that implement more commands and provide more options and operational modes to the user. However, with the interfaces of certain existing devices, these commands may be hidden behind many hierarchical levels of sub-menus and may not be immediately or intuitively apparent to the user. In other instances, a set of commands may not be logically grouped from a clinical point of view on the keypad or in the logical menu structure such that the user may get lost navigating through the multiple buttons and sub-menu options. Similarly, multiple operational modes may confuse the user who may lose track of the operational mode currently in effect. For example, a physiological monitor inadvertently running in a simulation mode while connected to a real patient could confuse the user and represent a hazard if the data being displayed by the monitor was simulated data rather than the data from the patient connected to the monitor.
Touch screen input devices deliver flexibility to the UI designer, including the ability to implement an essentially infinite number of touch screen buttons or data entry boxes as well as last minute additions in software, without any need to add new hard keys or input devices. Thus, devices controlled by touch screens tend to have a reduced number of associated hard keys. The art of user interface design involves the careful balance of competing factors. For example, increased dependence on touch screen keys may lead to more hierarchical levels of sub-menus because it is generally not an option to show all the keys on one screen of limited size. However, having fewer hard keys could also mean that the medical device is dependent on touch screen keys and if the touch screen malfunctions, the medical device might lock up with the user no longer able to control system operation.
In yet other instances with existing medical devices, different physiological monitors may be stand-alone units that do not communicate with each other. The stand-alone monitors may be placed at different locations on different machines at different sites, such that a clinician practicing at multiple office based surgery locations, may have to look in different spots in each facility to inspect, for example, the electrocardiogram—a less than desirable situation. Considering the fact that multiple physiological parameters should be monitored (e.g., electrocardiogram, pulse oximetry data, noninvasive blood pressure, and capnometry readings), a clinician's ability to even find the available data, much less, to be able to cognitively integrate and analyze the relevant information on a real-time basis, can be severely limited. Furthermore, using the example of an anesthesia machine, a delivery subsystem's monitored machine parameter (e.g., inspired fraction of oxygen set by the O2 and N2O ball-in-tube rotameter settings) may be physically separate from the corresponding monitored physiological parameter, arterial oxygen saturation, SpO2. As an example, a monitored SpO2 value should be interpreted in the context of the delivered inspired fraction of oxygen (FiO2). Thus, separation of the FiO2 setting (machine parameter) and SpO2 display (related physiology parameter) and more generally separation of the therapy and corresponding monitored parameter(s) on a medical device are undesirable.
A UI may have a vital function as a window into the inner workings of a medical device to promote transparency of operation as well as to provide feedback that a user request has been performed. As an example of lack of transparency, in many existing patient monitoring devices, outdated data that is intermittently captured continues to be displayed even when the monitor has been turned off or placed in a standby mode. If the user has forgotten to turn the monitor back on after turning it off, he might be misled into thinking that the UI is displaying current physiologic data that is relevant for critical diagnostic and therapeutic decisions.
A properly designed UI should enhance the interactions within the clinician-machine-patient system. To lighten the cognitive workload or “data overload” of the user, instead of presenting raw data, the UI should present data that has already been processed into meaningful information that can be assimilated at a glance, thus providing timely decision support to the user.
User error can be prevented by clear and unambiguous controls and input devices. However other failure modes exist in current UI designs. For example, default settings can be the cause of mishaps as demonstrated by infusion pumps. When users mistakenly accepted the default concentration that was actually weaker than the actual drug concentration, drug overdose and death resulted. Confusion between units may also be the cause of error especially in situations where weight may be used to calculate drug infusion rates.
A UI should compensate for user forgetfulness, incorrect entry of data and lack of judgment as well as reducing memory load. In some current UIs, the user has to search the environment or the display of a device to identify what parameter is alarming, sometimes amid a cacophony of irritating alarms as well as determine which alarm is of highest priority, in the event of multiple alarms. Alarms on current UI designs sometimes generate alarms out of context. For example, alarms may sound when there is no patient connected to a medical device or at the end of the procedure when the patient is being disconnected from the device, perfect examples of alarms becoming a nuisance by telling the user something that is already known.